Data backup, recovery, and migration for OpenShift

This page describes how to back up and recover Data Control Tower (DCT) in OpenShift environments, as well as how to migrate between clusters or to a DCT appliance. The script-based backup supports lift-and-shift and blue-green deployment strategies, as well as one-off migration scenarios. This page refers to the two DCT servers as source and target.

Choose your backup approach

DCT on OpenShift supports two backup approaches. Choose based on your recovery needs:

Approach

Best for

What it captures

Portability

OpenShift-native volume snapshots (OADP / CSI / cloud provider tools)

Fast recovery within the same cluster or storage backend. Captures all persistent state in a single coordinated snapshot.

All DCT persistent volumes — PostgreSQL database, encryption keys, application state.

Tied to your storage backend and cluster. Cannot restore to a different cluster type or to an appliance.

Script-based backup (backup_restore.sh)

Migrating to a different cluster, a different namespace, or to an appliance. Maintaining portable, off-cluster backups. Blue-green or lift-and-shift deployments.

Full PostgreSQL database (all DCT application data) and encryption keys — accounts, passwords, access groups, engine registrations, dSource/VDB metadata, compliance configurations, bookmarks, operation history. Does not include Helm chart configuration (certificates, hostname, resource limits).

Portable across any DCT OpenShift or Kubernetes installation. Can also be used to restore to a DCT appliance.

Delphix recommends configuring at least one of these approaches at installation time. If your cluster already uses OADP (OpenShift API for Data Protection) or a cloud provider's managed backup service, extending that coverage to the DCT persistent volumes is the simplest path.

Support notice: Delphix supports the script-based backup solution described on this page. OpenShift-native volume snapshot approaches (OADP, CSI drivers, cloud provider backup tools) are third-party solutions. Delphix can provide general guidance on which volumes must be protected, but cannot provide direct support for configuring or troubleshooting those tools. Refer to your platform and tool vendor documentation for assistance.

If you are using an external database, OpenShift-native snapshots must still capture the encryption key volumes (gateway-data, masking-data, virtualization-app-data), and the external database must be backed up separately using your database provider's tooling. See External database support for details.

Script-based backup

The following prerequisites, backup steps, restore steps, and additional environment configuration all apply to the script-based backup approach (backup_restore.sh).

Prerequisites

  1. The source DCT server is up and running.

  2. The target DCT server is installed in a separate OpenShift cluster and running the same version as the source DCT server at the time of backup.

  3. Ability to share backup files from source to target environments.

  4. Sufficient access to perform oc commands on both the source and target clusters.

Backup steps

Download dct-support-tools from the downloads site. Once the file is downloaded, untar the file and open the backup-restore directory to find the backup_restore.sh and appliance_backup_restore.sh scripts.

Copy 
% tar -xzvf dct-support-tools-02132025.tar.gz
% ./
% ./backup-restore/
% ./backup-restore/README
% ./backup-restore/backup_restore.sh
% ./backup-restore/appliance_backup_restore.sh
% ./support-bundle/
% ./support-bundle/collect_bundle.sh
% ./support-bundle/README
% ./VERSION
% cd backup-restore

Transfer the backup_restore.sh script to the machine where you have permissions to execute oc commands against the DCT pods. You must install the bash shell to run the script, as well as the zip/unzip utilities.

Make sure DCT on OpenShift is running and execute the backup_restore.sh script. The script may need to run with sudo if root permissions are needed to run the oc commands. Use the -n flag, pass the namespace (if not using the default dct-services), and redirect the script output to the desired backup location. The size of the backup depends on the size of the DCT data to be backed up but is typically in the 1GB to 10GB range. The script may take several minutes to execute and does not print anything to the console in case of success.

% /bin/bash backup_restore.sh -n dct-services > dct-backup1.zip

Restore steps

Execute the backup_restore.sh script with the -r flag specifying the path to the backup file:

% /bin/bash backup_restore.sh -n dct-services -r dct-backup1.zip

The operation takes several minutes.

Additional environment configuration

The HELM chart's values.yaml contains information specific to your environment, such as certificates, hostname, or resource limits. You can update this information before or after the migration process. The standard installation and configuration process can be followed to update these values.

OpenShift-native volume snapshots

In addition to the script-based backup described above, OpenShift-native volume snapshot capabilities can be used to back up DCT persistent data. This approach uses your cluster's CSI (Container Storage Interface) driver and the Kubernetes VolumeSnapshot API, which is fully supported in OpenShift, to capture all DCT persistent volumes as a coordinated group in a single snapshot operation.

Which volumes to capture

The following DCT persistent volumes must all be included in the snapshot. Your backup tool should capture these together in a single snapshot operation to ensure consistency:

Persistent volume

Contents

Required?

gateway-data

Encryption key for sensitive application data

Yes — without this, database backups cannot be decrypted

masking-data

Encryption key for masking service data

Yes

virtualization-app-data

Encryption key for virtualization service data

Yes

gwdatabase-data

PostgreSQL database (all DCT application metadata)

Yes, unless using an external database

If you are using an external database, the gwdatabase-data volume is not used by DCT. Instead, back up the external database using your database provider's backup tooling. The encryption key volumes (gateway-data, masking-data, virtualization-app-data) must still be captured. A database backup without the corresponding encryption key backups cannot be restored.

The encryption keys in gateway-data, masking-data, and virtualization-app-data do not change after initial creation. They do not need to be snapshotted on the same schedule as the database, but must be available at restore time.

Tooling

Any OpenShift-compatible backup tool that supports VolumeSnapshots can be used, including:

  • OpenShift API for Data Protection (OADP): Red Hat's supported backup solution, built on Velero. OADP documentation

  • Kubernetes VolumeSnapshot API (requires a CSI driver that supports snapshots): Kubernetes VolumeSnapshots documentation

  • Cloud provider tools such as AWS Backup for ROSA, Azure Backup for ARO, or equivalent managed OpenShift backup services

Refer to your CSI driver and cloud provider documentation for snapshot scheduling and retention configuration.

When to use the script-based backup instead

The script-based backup described above produces a portable backup file that can be restored to any DCT OpenShift installation (or migrated to an appliance). Volume snapshots are tied to the storage backend and cluster. If you need cross-cluster or cross-platform portability, use the script-based approach.

Example deployment scenarios

An example of a lift and shift deployment could be:

  1. Backup the running source server pre-upgrade.

  2. Upgrade the source server to the desired version and confirm functionality.

  3. Backup the source server post-upgrade.

  4. Install a new target server as the same source server's post-upgrade version.

  5. Restore the source post-upgrade backup to the target server.

  6. Restart the target services and confirm functionality.

  7. Shutdown the source server or maintain it for further testing.

An example of a blue-green deployment could be:

  1. Backup the running source server.

  2. Install a new target server with the same source server's version.

  3. Restore the source backup to the target server.

  4. Restart the target services and confirm functionality.

  5. Upgrade the target server to the newer version and confirm functionality.

  6. Redirect traffic to the target server.

  7. Shutdown the source server or maintain it for a future blue-green deployment.